Dynomotion

Group: DynoMotion Message: 4103 From: Andrew Ford Date: 2/27/2012
Subject: CUI AMT encoder (in)accuracy
Hey guys,

I've been having a lot of trouble trying to get my servos tuned and generating a lot of hand-numbing/table-ratting oscillations instead.  Part of the problem is the accuracy of the CUI AMT-102 encoders I've been using.

I did a data capture (super awesome feature of using something programmable like KFLOP), and I'm attaching the results.  I've got captures from the CUI encoder at 2048 CPR, 384CPR, and a capture of an optical encoder I liberated from a printer which is approx 725CPR

2048 CPR mode is just about useless, the counts are all over the place during motion (it's stable when motionless). 

384 CPR still shows some noise, which in the data is a series of backtracks of 1 count during rotation.  I didn't try to analyze the raw data for rate of count changes, but there's almost certainly timing jitter there if it can backtrack a count.  I think the 192 CPR mode might still be useful for spindle rotation, and perhaps the 200 CPR mode is useful for steppers, I didn't test.

The optical encoder is solid and the data looks about as smooth as my hand rotation.

Looks like I'm getting some new optical encoders.
   @@attachment@@
Group: DynoMotion Message: 4104 From: himykabibble Date: 2/27/2012
Subject: Re: CUI AMT encoder (in)accuracy
Perhaps you got a bad one. I've been using CUI encoders for years, with no problems whatsoever. Given that they're only about $23, I'd buy another one and see if you get a better result.

Regards,
Ray L.

--- In DynoMotion@yahoogroups.com, Andrew Ford <ahford@...> wrote:
>
> Hey guys,
>
> I've been having a lot of trouble trying to get my servos tuned and
> generating a lot of hand-numbing/table-ratting oscillations instead. Part
> of the problem is the accuracy of the CUI AMT-102 encoders I've been using.
>
> I did a data capture (super awesome feature of using something programmable
> like KFLOP), and I'm attaching the results. I've got captures from the CUI
> encoder at 2048 CPR, 384CPR, and a capture of an optical encoder I
> liberated from a printer which is approx 725CPR
>
> 2048 CPR mode is just about useless, the counts are all over the place
> during motion (it's stable when motionless).
>
> 384 CPR still shows some noise, which in the data is a series of backtracks
> of 1 count during rotation. I didn't try to analyze the raw data for rate
> of count changes, but there's almost certainly timing jitter there if it
> can backtrack a count. I think the 192 CPR mode might still be useful for
> spindle rotation, and perhaps the 200 CPR mode is useful for steppers, I
> didn't test.
>
> The optical encoder is solid and the data looks about as smooth as my hand
> rotation.
>
> Looks like I'm getting some new optical encoders.
>
Group: DynoMotion Message: 4110 From: Andrew Ford Date: 2/27/2012
Subject: Re: CUI AMT encoder (in)accuracy
I tried two different ones, I'm afraid :)  They were about the same.  I'll send you the  program after work if you'd like to give it a shot.

I'm using a PWM input amp (AMC BD30A8) fed with one of KFLOP's 8-bit PWMs, which I think may be the other part of my tuning problem, perhaps the count errors weren't a problem in your setup.

On Mon, Feb 27, 2012 at 6:23 AM, himykabibble <jagboy@...> wrote:
 

Perhaps you got a bad one. I've been using CUI encoders for years, with no problems whatsoever. Given that they're only about $23, I'd buy another one and see if you get a better result.

Regards,
Ray L.



--- In DynoMotion@yahoogroups.com, Andrew Ford <ahford@...> wrote:
>
> Hey guys,
>
> I've been having a lot of trouble trying to get my servos tuned and
> generating a lot of hand-numbing/table-ratting oscillations instead. Part
> of the problem is the accuracy of the CUI AMT-102 encoders I've been using.
>
> I did a data capture (super awesome feature of using something programmable
> like KFLOP), and I'm attaching the results. I've got captures from the CUI
> encoder at 2048 CPR, 384CPR, and a capture of an optical encoder I
> liberated from a printer which is approx 725CPR
>
> 2048 CPR mode is just about useless, the counts are all over the place
> during motion (it's stable when motionless).
>
> 384 CPR still shows some noise, which in the data is a series of backtracks
> of 1 count during rotation. I didn't try to analyze the raw data for rate
> of count changes, but there's almost certainly timing jitter there if it
> can backtrack a count. I think the 192 CPR mode might still be useful for
> spindle rotation, and perhaps the 200 CPR mode is useful for steppers, I
> didn't test.
>
> The optical encoder is solid and the data looks about as smooth as my hand
> rotation.
>
> Looks like I'm getting some new optical encoders.
>
Group: DynoMotion Message: 4111 From: Tom Kerekes Date: 2/27/2012
Subject: Re: CUI AMT encoder (in)accuracy [1 Attachment]
Hi Andrew,
 
Thanks for posting the data.  I often get asked about those as well as magnetic scales that also do a lot of interpolation.   The noise level is much greater than the resolution where with optical scales the noise is usually far less than the resolution.  They also have some lag an output pulses at an irregular rate.
 
But all that being said they can often be made to work ok.  The noise is usually averaged out by the slow motor response.  However the noise might be so high that it causes output saturation.  Try adding a 2nd order low pass filter at maybe 500Hz and Q of 1.4.  Use the Step response screen and do a plot so you can see the noise and how it affects the output.
 
Regards
TK   
Group: DynoMotion Message: 4128 From: Andrew Ford Date: 2/27/2012
Subject: Re: CUI AMT encoder (in)accuracy
Here's the program if you want to give it a shot, Ray.  I used excel to take the difference btw. successive positions & timers and generate a scatter graph, and of course you can generate the differences inside the program instead.


#include "KMotionDef.h"

#define N 10000

main()
{
    int i,k;
    double *p=gather_buffer;

    SetBitDirection(40, 1);
    SetStateBit(40, 0);

    // Wait until 40 is triggered.
    while(!ReadBit(40));
   
    SetStateBit(40, 0);
   
    printf("Capture Started\n");
   
    for (i = 0; i < N; i++)
    {
        WaitNextTimeSlice();
       
        *p++ = Time_sec();
        *p++ = (double)(TIMER0);

        *p++ = ch0->Position;
    }
   
    p=gather_buffer;
   
    printf("Capture Complete\n");

    FILE *f=fopen("C:\\temp\\encoder_pos_data.csv","wt");
    fprintf(f, "Time_Sec,HardwareClock,Position\n");
    for (i = 0; i < N; i++)
    {
        fprintf(f,"%16.9f,%d,%16.0f,\n",p[0], (int)p[1], p[2]);
        p += 3;
    }
    fclose(f);
   
    printf("Done\n");
}


On Mon, Feb 27, 2012 at 6:23 AM, himykabibble <jagboy@...> wrote:
 

Perhaps you got a bad one. I've been using CUI encoders for years, with no problems whatsoever. Given that they're only about $23, I'd buy another one and see if you get a better result.

Regards,
Ray L.



--- In DynoMotion@yahoogroups.com, Andrew Ford <ahford@...> wrote:
>
> Hey guys,
>
> I've been having a lot of trouble trying to get my servos tuned and
> generating a lot of hand-numbing/table-ratting oscillations instead. Part
> of the problem is the accuracy of the CUI AMT-102 encoders I've been using.
>
> I did a data capture (super awesome feature of using something programmable
> like KFLOP), and I'm attaching the results. I've got captures from the CUI
> encoder at 2048 CPR, 384CPR, and a capture of an optical encoder I
> liberated from a printer which is approx 725CPR
>
> 2048 CPR mode is just about useless, the counts are all over the place
> during motion (it's stable when motionless).
>
> 384 CPR still shows some noise, which in the data is a series of backtracks
> of 1 count during rotation. I didn't try to analyze the raw data for rate
> of count changes, but there's almost certainly timing jitter there if it
> can backtrack a count. I think the 192 CPR mode might still be useful for
> spindle rotation, and perhaps the 200 CPR mode is useful for steppers, I
> didn't test.
>
> The optical encoder is solid and the data looks about as smooth as my hand
> rotation.
>
> Looks like I'm getting some new optical encoders.
>
Group: DynoMotion Message: 4129 From: Andrew Ford Date: 2/27/2012
Subject: Re: CUI AMT encoder (in)accuracy
I don't think it's going to be good enough for the cross-slide on my lathe.  If the count is changing more than necessary and causing motor vibration while the cross-slide is holding a cutting diameter it's going to show up in the finish on the part.  1024 line avago encoders are $57.50 each from mouser in any case, pretty reasonable.  Mouser also seems to have better prices than digi-key on amp circular connectors, time to figure out what I want.



On Mon, Feb 27, 2012 at 11:56 AM, Tom Kerekes <tk@...> wrote:
 

Hi Andrew,
 
Thanks for posting the data.  I often get asked about those as well as magnetic scales that also do a lot of interpolation.   The noise level is much greater than the resolution where with optical scales the noise is usually far less than the resolution.  They also have some lag an output pulses at an irregular rate.
 
But all that being said they can often be made to work ok.  The noise is usually averaged out by the slow motor response.  However the noise might be so high that it causes output saturation.  Try adding a 2nd order low pass filter at maybe 500Hz and Q of 1.4.  Use the Step response screen and do a plot so you can see the noise and how it affects the output.
 
Regards
TK